Recently, a so-called multiprocessor system having multiple processors has been used in the fields of scientific computation, simulation and the like. Meanwhile, in the field of simulation, the development of which has been particularly facilitated only recently, there is simulation software for plants of mechatronics products, such as robots, automobiles, and airplanes. With the benefit of the development of electronic components and software technology, most parts of a robot, an automobile, an airplane, and the like are electronically controlled by using wire connections laid like a network of nerves, a wireless LAN, or the like.
Although these are mechatronics devices in nature, they also incorporate large amounts of control software. Therefore, the development of such a product has required to spend a long time period, enormous costs and a large pool of manpower to develop a control program and test the program.
As a conventional technique for such a test, there is HILS (Hardware In the Loop Simulation). Particularly, an environment for testing all the electronic control units (ECUs) in an automobile is called full-vehicle HILS. In the full-vehicle HILS, a test is conducted in a laboratory according to a predetermined scenario by connecting a real ECU to a dedicated hardware device emulating an engine, a transmission mechanism, or the like. The output from the ECU is input to a monitoring computer, and further displayed on a display to allow a person in charge of the test to view the display in order to check if there is any abnormal action.
However, in HILS, the dedicated hardware device is used, and the device and the real ECU have to be physically wired. Thus, HILS involves a lot of preparation. Further, when a test is conducted by replacing the ECU with another, the device and the ECU have to be physically reconnected, requiring even more work. Further, since the test uses the real ECU, it takes an actual time to conduct the test. Therefore, it takes an immense amount of time to test many scenarios. In addition, the hardware device for emulation of HILS is generally very expensive.
Therefore, there has recently been proposed a technique for configuring the entire simulation in software without using such an expensive emulation hardware device. In the technique, continuous simulation is used for plant parts, such as engines or transmissions, and a state chart or actual software code is used for controller parts. Depending on the simulation method for the controller parts, the former is called MIL (Model-in-the-Loop) simulation, and the latter is called SIL (Software-in-the-Loop) simulation. According to MIL or SIL, a test can be conducted without the hardware of any ECU.
As a system for supporting such a configuration of MIL/SIL, for example, there is a simulation modeling system, MATLAB®/Simulink® available from Mathworks Inc. In the case of using MATLAB®/Simulink®, functional blocks are arranged on a screen through a graphical interface, and a flow of processing is specified, thereby enabling the creation of a simulation program. Here, the functional blocks include the types of blocks for invoking basic operations such as addition and multiplication, integration, conditional branching, and further software code, and each block has input and/or output, respectively. The simulation including software blocks as the expression of a controller is SIL.
In the following description, when the units of such simulation are coupled together, each simulator is called a logical process. As a method of operating a coupled simulation system composed of multiple logical processes, parallel discrete event simulation is known. For example, Non-Patent Document 1 discloses a parallel discrete event simulation method using multiple logical processes. According to this paper, it is shown that the causality just has to be preserved locally in each logical process to avoid timing inconsistencies in the system and to guarantee the preservation of event causalities across logical processes. Since system-wide synchronous processing is unnecessary, no synchronous overhead is required.
FIG. 1 is a block diagram showing part of the configuration of an automotive simulation system composed of multiple logical processes. The system in FIG. 1 has a CAN emulator 102, an ECU emulator 104, an engine simulator 106, an ECU emulator 108, and a transmission simulator 110, each of which is a logical process implemented in software. In FIG. 1, the logical processes work in cooperation with each other while exchanging messages to give notice of events.
Time information is added to each event, and this means a simulation time at which a logical process on the receiving side performs processing. In the event time information, it is not allowed to set a time older than the simulation time of a logical process on the sending side. This is because past-time processing cannot be requested. If parts are interconnected through a network, since transmission therebetween is delayed, the receiving time shall be larger in value than the sending time. In a case of performing processing by using a timer function or the like, a time difference can be provided between the time (send) at which the timer is set and the time (receive) of generating an alarm, or if the receiving side allows for a certain amount of delay, the allowed range can be set as the time difference.
In regard to event communication between two logical processes A and B, time differences between the send time and the receive time are classified into time lags and schematically shown in FIG. 2.
FIG. 2(1) is the case with no time lag, showing a strong-coupled structure in which A and B cannot be executed in parallel. This case cannot be divided into different logical processes, and hence required to perform calculations as a single simulator. If the structure allows for some errors and A and B are executed in parallel every short time period, it will be weak-coupled simulation.
FIG. 2(2) shows a case where both time lag LAB from A to B and time lag LBA from B to A are not zero. In this case, synchronous processing is performed with a time step of the greatest common divisor thereof to enable coupled simulation without time error even in parallel operations.
FIG. 2(3) shows a case where the time lag LAB from A to B is not zero but the time lag LBA from B to A is virtually zero. In this case, it is expected every moment to update data in the direction from B to A, A cannot move forward even one step until an event is notified from B. Therefore, both have no choice but to achieve sequential running alternately, lowering the execution speed.
In the case of FIG. 2(3), for example, logical process A is an ECU emulator and logical process B is a plant simulator. The case of FIG. 2(3) can also occur in the sense that data transmission is performed immediately even between ECU emulators and between plant simulators but data reception involves a communication delay. A similar problem can also arise if the time lag is not zero but very small.
Since the case of FIG. 2(3) often appears in the parallel discrete event simulation system using logical processes, a method of enabling parallel execution in the case of FIG. 2(3) is desired.
To prevent the logical processes from waiting for events from each other and hence causing deadlock, a technique using a null message is known. However, when the time lag is zero, no future time is given to the null message, deadlock is not caused but parallel execution cannot be achieved.
Non-Patent Document 2 provides a technique called ε-lookahead execution to such a problem, giving one solution. In other words, ε-lookahead execution is a method of running processes in parallel in the system of FIG. 2(2) on the assumption that there is a time lag of ε as close to zero as possible. In this case, errors are accumulated due to inaccurate data switching timings. In order to increase accuracy, it is necessary to reduce the value of ε, but when it happens, the execution speed is reduced, resulting in a tradeoff between accuracy and execution speed.